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FUNCTION INJECTOR 

FIELD OF THE INVENTION 

This invention relates generally to testing computer program code, and more 
5 particularly to invoking fault conditions during the testing of computer program code. 

COPYRIGHT NOTICE/PERMISSION 

A portion of the disclosure of this patent document contains material, which is subject 
to copyright protection. The copyright owner has no objection to the facsimile reproduction 
10 by anyone of the patent document or the patent disclosure as it appears in the Patent and 
Trademark Office patent file or records, but otherwise reserves all copyright rights 
whatsoever. The following notice applies to the software and data as described below and in 
the drawings hereto: Copyright © 2000, Microsoft Corporation, All Rights Reserved. 

1 5 BACKGROUND OF THE INVENTION 

Computer programs have become increasingly more complex as they provide more 
and more features. As the complexity increases, the probability that a computer program will 
have a programming error (commonly referred to as a "bug") increases dramatically. To 
reduce the probability of distributing a computer program with a programming error, 
20 developers of computer program perform extensive testing. Because of the importance of 
thorough testing and because such testing can be very time-consuming, computer program 
developers have developed extensive testing procedures. 

In order to make a computer program application reliable for its intended audience, 
whether that be a commercial distribution of thousands of copies as a major software product 
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offering to the public at large, or internal use distribution, as a tool to a department sized work 
group of a dozen people or less, the area of software testing has emerged as the primary 
vehicle for assuring quality software products and for rooting out and resolving as many bugs 
as possible. In the field of testing, an attempt is made to exercise the software in as many 
5 different ways as possible in order to catch as many programming errors as possible before 
"releasing" the software for general use. Bugs not caught before release are very costly to an 
enterprise both in terms of rectifying the errors and in the loss of goodwill due to perceptions 
regarding the quality of the software. 

Computer program code is tested using one of a number of conventional methods, 
10 including artificially simulating a fault condition by stepping through the executable file in a 
debugger and manually changing the instruction pointer or memory value, modifying the 
source code by introducing debug statements or routines into the program and observing the 
results during program execution, limiting system resources, writing replacement function 
libraries using user controllable settings, or intercepting functions at run-time and diverting 
1 5 control execution to a replacement function. 

Another technique is redirecting a function, as in U.S. Patent 5,812,828, in which a 
call to a function is replaced with a call to a user-supplied function. However, this technique 
suffers from the same drawback that all techniques that use a replacement function suffer 
from: the location, or entry point address, of the original redirected function is not retained, 
20 therefore, the original redirected function cannot be accessed. In this case, the original 
redirected function is merely simulated, the original redirected function is never used or 
accessed by the user-supplied function. This limits developers and testers in the testing of the 
function because the original function must often be used to exactly reproduce a fault. 



25 SUMMARY OF THE INVENTION 

In general, the invention enables an author of a computer program to easily inject a 
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fault into an executable file. More specifically, the invention instraments an executable file so 
that an instramented function call or method invocation is redirected to a user-supplied 
function, and the user-supplied function is able to invoke the instrumented function in the 
original context of stack and registers because the instrumented function address is saved in a 
5 table in the executable file. The invention also enables publication, or export, of a function 
that v^as not exported during compilation or linking, and enables the user-supplied function(s) 
to invoke the published function. 

More specifically, the function lookup table maps or associates, the address of the 
original function with the name of the original function, when the executable file is 

10 instrumented. The instrumented code is modified such that the address of the instrumented 
function is saved in a threaded local storage (TLS) variable. Each user-supplied function that 
invokes the original instrumented function uses the name of the instrumented function to 
verify that the address in the TLS variable is the same as the address in the function lookup 
table. Upon verification, the user-supplied function invokes the instrumented function using 

1 5 the verified address. A LookupFunctionAddressQ function retrieves the address of an 
instrumented function and a LookupMethodAddress() function retrieves the address of an 
instrumented object-oriented class method. 

A master lookup table that maps the base addresses of the instrumented executable 
files to the address of the function lookup tables is created at runtime of the instrumented 
20 executable file by an injector runtime library that looks up the original function address. The 
injector runtime library that looks up the original function address is separate from the 
instrumented executable file. Furthermore, the injector runtime library that looks up the 
original function address executes at the same time as the instrumented executable file and a 
user-supplied function library. 

25 In addition, the present invention enables logging of events for the purposes of 

statistical analysis or as data added to a software "bug" report, enables substitution of one 
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library application program interface (API) for another API for purposes of proof-of-concept 
or hot-fix, and enables addition of functionality to an executable file without modifying the 
source code of executable file. 

In one aspect of the present invention, a method for creating an instrumented 
5 executable file includes redirecting an original function in an executable file to a user-supplied 
function and retaining access information of the original fiinction. During execution of an 
executable file, a user-supplied fiinction invokes the original fimction using the retained 
access information of the original function. The original function in varying embodiments is 
embedded in the executable file or is in a dynamic link library (DLL). An embedded function 
10 is a function that physically resides in the same file that contains a main() function entry 

point. The method further enables the user-supplied function to invoke the original function 
by adding a call in the user-supplied function to a function that retrieves the retained address 
of the original function, by adding an invocation in the user-supplied-function that invokes the 
original function firom the address of the original function. 

15 Dynamic control of the user-supplied function and the original function is 

accomplished by adding set point management control functions to the user-supplied function 
that access one or more data files, such as an initialization (INI) file, to retrieve control and 
command information. 

In another aspect of the present invention, a method for instrumenting a function 
20 imported into an executable file. The method includes adding a wrapper of the imported 

function to the import data block, and the method includes adding to the executable file, a stub 
function for the imported function that saves the original function address to a TLS variable 
and causes a jump to the user-supplied function. The method also includes adding to a 
function lookup table, an entry mapping the address of the original imported function to the 
25 name of the original imported function. 

In yet another aspect of the invention, a method for instrumenting a function that is 
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embedded in an executable file, includes modifying an embedded function to jump to the 
user-supplied function and adding an entry in a function lookup table of the original 
embedded function address. 

In still another aspect of the present invention, a method for executing an instrumented 
5 executable file that calls an original function that jumps to a user-supplied function, the 
method includes determining whether the function implements a thiscall calling convention 
and if so, then injecting code to push the register that holds the 'this' pointer onto the stack 
from the called function site and swap the return value of a calling function on the stack and 
the ECX register value on the stack. The original function may be imported or embedded in 
1 0 the executable file. 

In still yet another aspect of the invention, a computer system includes a first module 
of machine-readable code, such as an executable file that includes a instrumented function 
jump to a replacement (user-supplied) function and a data structure, such as a table associating 
the identity of the instrumented function with the location of the instrumented function, and 
1 5 includes a second module comprising the replacement (user-supplied) function, operatively 
coupled to the first module through an invocation of the original function. 

In an additional aspect of the invention, a method for publishing a function that was 
not previously exported includes adding an entry describing the function in a function lookup 
table in a machine-readable executable file. 

20 In a final aspect of the invention, set points enable a user-supplied wrapper function to 

be v^itten once, and its functionality can be altered in various ways under the direction of data 
stored in a separate file, such as initialization file or registry. In being data driven, the user- 
supplied function does not need to be modified and recompiled in order to simulate a different 
fault. Furthermore, the present invention performs fault detection, in which the user-supplied 

25 function invokes the original instrumented function and afterward attempts to verify 
successful completion of the original function. 
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The present invention describes systems, clients, servers, methods, and computer- 
readable media of varying scope. In addition to the aspects and advantages of the present 
invention described in this summary, further aspects and advantages of the invention will 
become apparent by reference to the drawings and by reading the detailed description that 
5 follows. 

The invention as embodied is a general purpose software product that can be 
incorporated into a specific test program designed to test a particular API, internal functions 
that are not intended to be utilized by anyone else but the developer, and all the subroutines 
therein. By including this embodiment of the invention into the test program, the writing of 
10 the test program is simplified and streamlined so as to save time and money with respect to 
test program development. In addition by not requiring the tester/developer to modify the 
original source code, potential new bugs/errors will not mistakenly be introduced. 



BRIEF DESCRIPTION OF THE DRAWINGS 

15 FIG. 1 shows a diagram of the hardware and operating environment in conjunction 

with which embodiments of the invention may be practiced; 

FIG. 2 is a diagram illustrating a system-level overview of an exemplary embodiment 
of the invention; 

FIG. 3 is a flowchart of a method of instrumenting a function in an executable file 
20 with a user-supplied function in a maimer that preserves access information of the 

instrumented function, to be performed by a computer according to an exemplary embodiment 
of the invention; 

FIG. 4 is a flowchart of a method of publishing an instrumented function, to be 
performed by a computer according to an exemplary embodiment of the invention; 

25 FIG. 5 is a block diagram of a system including an executable file, a software 
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component having a user-supplied function, and an apparatus for instrumenting the executable 
file using the software component 

FIG. 6 is a diagram of a function lookup table data structure for use in an exemplary 
implementation of the invention. 

5 

DETAILED DESCRIPTION OF THE INVENTION 

In the following detailed description of exemplary embodiments of the invention, 
reference is made to the accompanying drawings which form a part hereof, and in which is 
shown by way of illustration specific exemplary embodiments in which the invention may be 

10 practiced. These embodiments are described in sufficient detail to enable those skilled in the 
art to practice the invention, and it is to be understood that other embodiments may be utilized 
and that logical, mechanical, electrical and other changes may be made without departing 
from the scope of the present invention. The following detailed description is, therefore, not 
to be taken in a limiting sense, and the scope of the present invention is defined only by the 

1 5 appended claims . 

The detailed description is divided into five sections. In the first section, the hardware 
and the operating environment in conjunction with which embodiments of the invention may 
be practiced are described. In the second section, a system level overview of the invention is 
presented. In the third section, methods for an exemplary embodiment of the invention are 
20 provided. In the fourth section, a particular implementation of the invention is described. 
Finally, in the fifth section, a conclusion of the detailed description is provided. 



Hardware and Operating Environment 

FIG. 1 is a diagram of the hardware and operating environment in conjunction with 
25 which embodiments of the invention may be practiced. The description of FIG. 1 is intended 
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to provide a brief, general description of suitable computer hardware and a suitable computing 
environment in conjunction v^ith which the invention may be implemented. Although not 
required, the invention is described in the general context of computer-executable instructions, 
such as program modules, being executed by a computer, such as a personal computer. 
5 Generally, program modules include routines, programs, objects, components, data structures, 
etc., that perform particular tasks or implement particular abstract data types. 

Moreover, those skilled in the art will appreciate that the invention may be practiced 
with other computer system configurations, including hand-held devices, multiprocessor 
systems, microprocessor-based or programmable consumer electronics, network PCs, 
1 0 minicomputers, mainframe computers, and the like. The invention may also be practiced in 
distributed computing environments where tasks are performed by remote processing devices 
that are linked through a communications network. In a distributed computing environment, 
program modules may be located in both local and remote memory storage devices. 

The exemplary hardware and operating environment of FIG. 1 for implementing the 
1 5 invention includes a general purpose computing device in the form of a computer 20, 

including a processing unit 21, a system memory 22, and a system bus 23 that operatively 
couples various system components, including the system memory to the processing xmit 21. 
There may be only one or there may be more than one processing unit 21, such that the 
processor of computer 20 comprises a single central-processing unit (CPU), or a plurality of 
20 processing units, commonly referred to as a parallel processing environment. The computer 
20 may be a conventional computer, a distributed computer, or any other type of computer; 
the invention is not so limited. 

The system bus 23 may be any of several types of bus structures including a memory 
bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus 
25 architectures. The system memory may also be referred to as simply the memory, and 
includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic 
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input/output system (BIOS) 26, containing the basic routines that help to transfer information 
between elements within the computer 20, such as during start-up, is stored in ROM 24. The 
computer 20 fiirther includes a hard disk drive 27 for reading from and writing to a hard disk, 
not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 
5 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 3 1 
such as a CD ROM or other optical media. 

The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected 
to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and 
an optical disk drive interface 34, respectively. The drives and their associated computer- 
1 0 readable media provide nonvolatile storage of computer-readable instructions, data structures, 
program modules and other data for the computer 20. It should be appreciated by those 
skilled in the art that any type of computer-readable media which can store data that is 
accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, 
Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the 
1 5 like, may be used in the exemplary operating environment. 

A number of program modules may be stored on the hard disk, magnetic disk 29, 
optical disk 31, ROM 24, or RAM 25, including an operating system 35, one or more 
application programs 36, other program modules 37, and program data 38. A user may enter 
commands and information into the personal computer 20 through input devices such as a 
20 keyboard 40 and pointing device 42. Other input devices (not shown) may include a 

microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input 
devices are often connected to the processing unit 21 through a serial port interface 46 that is 
coupled to the system bus, but may be connected by other interfaces, such as a parallel port, 
game port, or a universal serial bus (USB). A monitor 47 or other type of display device is 
25 also connected to the system bus 23 via an interface, such as a video adapter 48. In addition 
to the monitor, computers typically include other peripheral output devices (not shown), such 
as speakers and printers. 

9 
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The computer 20 may operate in a networked environment using logical connections 
to one or more remote computers, such as remote computer 49. These logical connections are 
achieved by a communication device coupled to or a part of the computer 20; the invention is 
not limited to a particular type of communications device. The remote computer 49 may be 
5 another computer, a server, a router, a network PC, a client, a peer device or other common 
network node, and typically includes many or all of the elements described above relative to 
the computer 20, although only a memory storage device 50 has been illustrated in FIG. 1. 
The logical connections depicted in FIG. 1 include a local-area network (LAN) 51 and a wide- 
area network (WAN) 52. Such networking environments are commonplace in offices, 
1 0 enterprise-wide computer networks, intranets and the Internet. 

When used in a LAN-networking environment, the computer 20 is connected to the 
local network 5 1 through a network interface or adapter 53, which is one type of 
communications device. When used in a WAN-networking environment, the computer 20 
typically includes a modem 54, a type of communications device, or any other type of 
1 5 communications device for establishing communications over the wide area network 52, such 
as the Internet. The modem 54, which may be internal or external, is connected to the system 
bus 23 via the serial port interface 46. In a networked environment, program modules 
depicted relative to the personal computer 20, or portions thereof, may be stored in the remote 
memory storage device. It is appreciated that the network connections shown are exemplary 
20 and other means of and communications devices for establishing a communications link 
between the computers may be used. 

The hardware and operating environment in conjunction with which embodiments of 
the invention may be practiced has been described. The computer in conjunction with which 
embodiments of the invention may be practiced may be a conventional computer, a distributed 
25 computer, or any other type of computer; the invention is not so limhed. Such a computer 
typically includes one or more processing units as its processor, and a computer-readable 
medium such as a memory. The computer may also include a communications device such as 

10 
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a network adapter or a modem, so that it is able to communicatively couple to other 
computers. 

System Level Overview 

5 A system level overview of the operation of an exemplary embodiment of the 

invention is described by reference to FIG. 2. 

System 200 includes an instrumented executable file 210 that is modified from an 
original module (not shown) to replace, substitute or instrument access 220 to an original 
function 230, with an access 240 to a user-supplied function 250. The user-supplied function 

10 250 optionally includes an access mechanism 260 to the original function 230. The user- 
supplied function 250 is alternatively described as a "wrapper" when the user-supplied 
function 250 optionally "wraps" or includes access to the original function 230. 

More specifically, the original function 230 and the user-supplied function 250 in 
varying embodiments are functions or object methods. 

1 5 In one embodiment, instrumented executable file 21 0 is instrumented in a manner such 

that an original function 230 that is contained or embedded within the instrumented 
executable file 210 (not shown) includes an invocation or redirection 260 to a user-supplied 
function 250. 

System 200 enables instrumenting an original function 230 in an executable file using 
20 a user-supplied fimction 250, in a manner that enables the user-supplied function 250 to 

invoke the original function 230, regardless of whether the original function 230 is imported 
from a dynamic Unk library is implemented in the executable file 210. 

System 200 also includes a mechanism to retain information required to access the 
original function. In one embodiment, the mechanism is a table 270 in the instrumented 
25 executable file 2 1 0 that maps or associates the name of the original fimction 230 with the 
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address of the original function 230. The mechanism enables the user-supplied function 250 
to locate the original function 230. The table 270 is described in detail in conjunction with 
FIG. 6. 

Optionally, system 200 includes an injector runtime library 280. At initialization of 
5 the run tune library, a master lookup table 290 is created, that relates the base address of the 
instrumented executable file 210 to the address of the lookup table of the instrumented 
executable file. The master lookup table 290 assists in locating the address of the lookup 
table of instrumented executable program. 

The system level overview of the operation of an exemplary embodiment of the 
1 0 invention has been described in this section of the detailed description. The system level 
overview describes a system for enabling an instrumented executable file to retain access 
information, such as the entry point address, of an instrumented executable file so that a user- 
supplied function can access the original function. The invention is not limited to any 
particular implementation of instrumented executable file or component. 

15 

Methods of an Exemplary Embodime nt of the Invention 

In the previous section, a system level overview of the operation of an exemplary 
embodiment of the invention was described. In this section, the particular methods performed 
by the server and the clients of such an exemplary embodiment are described by reference to a 

20 series of flowcharts. The methods to be performed by the clients constitute computer 

programs made up of computer-executable instructions. Describing the methods by reference 
to a flowchart enables one skilled in the art to develop such programs including such 
instructions to carry out the methods on suitable computerized clients (the processor of the 
clients executing the instructions from computer-readable media). Similarly, the methods to 

25 be performed by the server constitute computer programs also made up of computer- 
executable instructions. Describing the methods by reference to flowcharts enables one 
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skilled in the art to develop programs including instructions to carry out the methods on a 
suitable computerized server (the processor of the clients executing the instructions from 
computer-readable media). 

FIG. 3 is a flowchart of a method of instrumenting a function in an executable file 
5 with a user-supplied function in a manner that preserves access information of the 
instrumented function, to be performed by a computer, according to an exemplary 
embodiment of the invention. 

Method 300 begins by opening a binary image of an executable file to be instrumented 
305. A list (not shown) of the function(s) in the executable file that are to be instrumented, 
1 0 known as a "wrap function lisf is also specified. Thereafter, each of the functions identified 
in the wrap function list are instrumented. 

To instrument each of the functions identified in the wrap function list, the next entry 
in the wrap function list is retrieved 310. Thereafter, the list of procedures/functions is 
enumerated and a determination of whether or not the function exists is made (not shown). If 
15 the function does not exist, then the method continues at action 310, where the next item from 
the wrap function list is retrieved. 

Continuing, a determination is made as to whether the retrieved function is imported 
or not 315. 

In one embodiment, the determination is based on the .IDATA (import data) table 
20 present in an executable file of the portable executable (PE) file format. If the function name 
is found in the .IDATA table, it is imported from the specified module. If the function name 
is not found in the import table, the function exists within the executable file. The tool 
DUMPBIN in Microsoft VisualStudio can be used to display the list of imported functions. 

If the determination indicates the function is not imported, the function is instrumented 
25 pursuant and according to the requirements of an embedded, internal, local, or defined, 

function. Otherwise, the function is instrumented pursuant and according to the requirements 
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of an imported function. In one embodiment, an imported function is a function that is 
located, or resides outside of the executable file being instrumented, such as a dynamic link 
library (DLL). 

Instrumenting an embedded function begins with determining if the function is 
5 overloaded 320. An overloaded function is well-known to those skilled in the art as having the 
same name as of at least one other function within the same scope or domain, but with a 
different set of arguments or parameters. If the function is overloaded, a determination is 
made as to whether the function prototype of the function retrieved in action 3 10 is correctly 
specified 325. If the function prototype is not correctly specified, then the error is logged or 

1 0 recorded 330 and the instrumenting of the function that was retrieved fi-om the function 

wrapper in action 3 10 is aborted by returning control flow to action 3 1 0 in order to instrument 
the next function in the function wrapper list. If the function is not overloaded, or if the 
function is overloaded and the prototype of the function is correctly specified, then 
instrumenting of the embedded function continues by redirecting the original embedded 

15 function in the executable file to the user- supplied function 335. More specifically, the 

redirection 335 is performed by modifying the original function, such that the address of the 
original function is saved into the threaded local storage (TLS) variable. Subsequently, an 
instruction "JMP Wrapper_address" is added to the body of the original function. 
"Wrapper^address" is the user-supplied function to be re-directed to. More specifically the 

20 instruction is an assembly "JMP" instruction. 

Furthermore, the instrumented executable file does not need to be re-instrumented in 
order to change the behavior of the original function or the user-supplied function. Rather, in 
one embodiment, the behavior of the user- supplied function is altered using user- specified set 
points. The set points are stored in any data storage embodiment that is well-known to those 
25 skilled in the art, such as a registry file, an external file, the current system resource, and an 
initialization (INI) file. By being data driven, the user-specified wrapper function does not 
need to be modified and recompiled in order to simulate a different fault. 
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The method 300 also includes adding an entry in a function lookup table of the 
original module 340, which enables the user-supplied function to call the original function at 
run-time. The function lookup table is as in table 270 in FIG. 2. 

Where an original function is a class method that uses the ^thiscall calling 

5 convention, then the user-supplied function is prototyped or defined with an additional 

parameter, the "this" pointer which points to the object class, and method uses the stdcall 

calling convention. 

In one embodiment, if the original function is determined to be a C++ thiscall function 
355, then code is generated and inserted in the original function that pushes the ECX register 

10 value onto the stack and swaps the return address of the calling function on the stack and the 
ECX register value on the stack. This code is necessary to provide a correct stack before the 
jump to the user-supplied function. More specifically, the swap is performed because at the 
time the ECX registry value is pushed on to the stack in the original function, the return 
address of the calling function is already on the stack. Therefore, the return address and the 

1 5 ECX register value are swapped so that the "this" pointer stored in ECX has the correct 
position on the stack. 

In an alternative embodiment, if the original function is determined to use the thiscall 
calling convention, then action 360, pushing the register that holds the 'this' pointer onto the 
stack from the called function site and swapping the return value of the calling function on the 
20 stack and the ECX register value on the stack is performed. 

The use of the ECX register is to support the "this" pointer in C++ implementations. 
Conventionally, all non-static class methods require a "this" pointer. The "this" pointer points 
to the start of the specific instance of the instantiated object (i.e. class, data structure). The 
compiler places the "this" pointer in the ECX register instead of pushing it on the stack as an 
25 optimization. There is a high probability that one method will call another method within the 
same class. 



15 



MS docket 133015.1 SLWK docket 777.364.usl 

Instrumenting an imported user-supplied function begins with determining whether the 
function prototype of the user-supphed function retrieved in action 3 10 is correctly specified 
365, In one embodiment, where the imported function was written in C++, then the function 
prototype is made available through the portable executable (PE) file format. In another 
5 embodiment where the imported function is written in a language other than C++, only the 
base function name is available. In yet another embodiment, the module DLL that hosts the 
imported function is searched for its prototype directly from the source. 

If the function prototype is not correctly specified, then the error is logged or recorded 
370, similar to action 330, and the instrumenting of the user-supphed function that was 
1 0 retrieved in action 3 1 0 ends by returning control flow to action 3 1 0 in order to instrument the 
next user-supplied function in the list. 

If the prototype of the user- supplied function is correctly specified, then instrumenting 
of the imported function continues by adding the imported user-supplied function, or wrapper, 
to the import data block of the executable file 375. In one embodiment, an entry indicating 

1 5 the imported user-supplied function is added to the idata definitions in the executable file. 
The idata definitions identify imported functions. 

Continuing the instrumenting of an imported function, method 300 redirects all calls 
of the original imported function in the executable file to the user-supplied function 380. 
More specifically, redirecting an imported function includes adding a wrapper of the imported 

20 function to the import data block (.IDATA) in the instrumented executable file, adding a stub 
function for the imported function to the instrumented executable file, and redirect calls of the 
original function to the stub function. The stub function includes an instruction that saves the 
original function address to a threaded local storage variable and an instruction that causes a 
jump, such as an assembly "JMP" instruction, to the user-supplied function. 

25 The method also includes adding an entry in a function lookup table for the original 

imported function 385, which enables the user-supplied function to call the original function. 
The function lookup table is as in table 270 in FIG. 2. 
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If the original function is determined to be a C++ thiscall function 355, then code is 
generated and inserted in the stub function that pushes the ECX register value onto the stack 
and swaps the return address of the calling function on the stack and the ECX register value 
on the stack. This code is necessary to provide a correct stack before the jump to the user- 
5 supplied function. More specifically, the swap is performed because at the time the ECX 
registry value is pushed on to the stack in the original function, the return address of the 
calling function is already on the stack. Therefore, the return address and the ECX register 
value are swapped so that the "this" pointer stored in ECX has the correct position on the 
stack. 

10 Actions 375, 380, and 385 are performed in varying order in varying embodiments. 

Thereafter, if at least one additional entry remains in the wrap function list 390, the 
method 300 continues with action 310, Otherwise, the method 300 ends. 

As a result, the instrumented executable file does not need to be re-instrumented in 
order to change the behavior of the original function. Rather, the behavior of the user-supplied 
1 5 function is altered using user-specified set points, as described below in conjunction with FIG. 
5, via an external file, the registry, the current system resource, and other data sources well- 
known to those skilled in the art. 

Optionally, method 300 also includes generating and adding code to a wrapper 
function that invokes a setpoint manager. However, the wrapper function author does not 
20 need to invoke a setpoint manager in order to implement the wrapper function. Using a set 
point manager, however, will allow the wrapper function author to leverage this data-driven 
model and not need to focus on managing set points. 

Optionally, method 300 also includes generating and adding a call instruction to the 
instrumented executable file. At run-time, when the instrumented executable file is first 
25 executed, the call instruction will call a function to save in a master lookup table, such as 
master 290 in FIG. 2, the pointer or address of the instrumented executable file, as in table 
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270 in FIG. 2, in association with the name of the instrumented executable file. The function 
receives the pointer to the function lookup table of the instrumented executable file, as in table 
270 in FIG. 2, and the base address pointer of the executable file. At run-time, the master 
lookup table, as in table 290 in FIG. 2, is accessed using the TLS value as the compaiison 
5 criteria to retrieve the base address of the original instrumented executable file. Thereafter, 
the base address of the instrumented executable file is used to locate the function lookup table 
within the instrumented executable file, then the fianction lookup table, as in table 270 in FIG. 
2, is accessed to retrieve the address of the original function. 

Optionally, method 300 also adds machine instructions to the executable file to call the 
10 SaveWrappedFunctionAddressQ fimction to save the address of the original instrumented 
function in a global master lookup table, such as master 290 in FIG. 2. The 
LookupFunctionAddressO and LookupMethodAddressQ functions verify that the address 
found in the function lookup table, as in table 270 in FIG. 2, matches this value. 

At run-time, when the instrumented executable file is executed, a master lookup table 
15 is used to assist in locating the address of the original fiinction. The method to find the 

original function address of a wrapped fiinction is as follows: from the TLS variable, the run- 
time module can determine from the master lookup table, the base address of the module 
where the wrapped fi:inction resides. Then, the run-time module can locate the address of the 
function lookup table, as in table 2 in FIG. 2, from the master lookup table. From the function 
20 lookup table, the run-time module can match the function name with its original address, 

FIG. 4 is a flowchart of a method of publishing an instrumented function, to be 
performed by a computer according to an exemplary embodiment of the invention. Method 
400 is optionally performed subsequent to method 300, The method enables a first function to 
be called from a second function after compilation and linking where the first function has not 
25 been exported by a linker or compiler. 

Method 400 begins by retrieving an item from a list of functions that are to be 
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published 410 that was not previously exported by the linker or compiler. Each item in the 
list uniquely identifies, by name and prototype, a function to be published. Thereafter, a 
determination of whether the function name exists 420 and a determination of whether the 
function prototype is correctly specified 430 is performed in order to verify that the function 
5 to be published exists. If the determinations succeed, then the function is published by adding 
the entry for the function in the function lookup table 440, as in action 340 and action 385 in 
FIG. 3. If the determinations fail, then the error is logged, 450 and 460, respectively. 
Continuing, the method 400 determines whether or not another item is available in the list 
470. If another function is available, the method 400 continues by retrieving the function 
10 from the list in action 410. Otherwise, all of the functions that the list specifies for publishing 
are processed, and the method 400 ends. 



Implementation 

In this section of the detailed description, a particular implementation of the invention 
15 is described. The Implementation section is divided into 5 sections; instrumenting, 

overloaded functions and methods, set point management and run-time, fault simulation, and 
fault detection. 

Instrumenting 

FIG. 5 is a block diagram of a system 500 including an executable file, a software 
20 component having a user-supplied function, and an apparatus for instrumenting the executable 
file using the software component. System 500 includes an executable file 510, which has a 
machine-readable instruction that is a call to an original function that will be instrumented or 
a definition of an original function that will be instrumented. The source code of an example 
that is compiled and linked in the executable file 5 1 0 follows in table 1 : 

25 
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void main (int argc, char * argv[]) 
{ 

A(6); 
B(7); 

5 }; 

void A(int z) 

( 

return; 

}; 

10 

Table 1 



The source code in table 1 includes a function name "main ()" which is the entry point 
1 5 of execution, and includes calls to functions A() and B(). The functions in the program that 
are instrumented are the original functions before instrumenting, and have a unique identity, 
which includes a name, such as "A" and a parameter, such as "int z". 

Executable file 510 is operatively coupled to a dynamic link library (DLL) 520 
through compiling and linking operations performed on the executable file 510 and the DLL 
20 520. The DLL 520 is comprised of one of more fimctions, such as the following in Table 2: 



void B(int x) 

{ 

return; 

25 }; 



Table 2 



The system 500 also includes apparatus 530, which is a program that performs 
30 methods of instrumenting and publishing function(s) according to the present invention, as in 
method 300 and method 400, respectively. The apparatus 530 receives from a source of 
instrument commands 540, the identity, such as "void A(int z)", or "void B(int x)" of the 
original function in the executable file that is to be instrumented, and the identity, such as 
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"void A_W(int z)", of a user-supplied function (not shown), as in action 310 in FIG. 3. In 
one embodiment, the source of instrument commands 540 is a data file, where the data file is 
created by a program that solicits instrumentation commands from users. 

Furthermore, apparatus 530 instruments a function in the executable file. 
5 Instrumenting uses the identity of a user-supplied fimction and the identity of an original 
function received from the source of instrument commands 540. 

For example, to instrument embedded function A() in Table 1 with user-supplied 
function A_W(), A() in Main() is modified by adding a save of the address of A() in a TLS 
variable, adding an invocation of A_W() and as follows in Table 3: 

10 

void main (int argc, char ^ argv[]) 

{ 

A(6); 
B(7); 

15 }; 

void A(int z) 

{ 

TLS_var=&A; 
jmp A_W; 

20 retxim; 

}; 

Table 3 

25 Instrumenting an embedded function is also described in conjunction with actions 330 

through 360 in FIG. 3. 

In another example, to instrument calls in Table 1 to imported function B() with user- 
supplied function B_W(), the call to B() in Main() is replaced with a call a stub for B_W() as 
follows in Table 4: 

30 

void main (int argc, char * argvQ) 
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{ 

A(6); 
stub_B(7); 

}; 

5 void A(int z) 

{ 

return; 

}; 

stub_B(int Y) 
10 { 

TLS_var=&B; 
jpmB_W(); 

} 

15 Table 4 



Instrumenting an imported function is also described in conjunction with actions 365 
and 385 in FIG 3. 

20 Apparatus 530 also stores the address of the original instrumented function in the 

executable file in association with the name of the original instrumented function, which 
enables the user-supplied function to call the original instrumented. Storing the address of the 
original instrumented function in the executable file is also described in conjunction with 
actions 340 and 385 in FIG 3. 

25 FIG. 6 is a diagram of a function lookup table 600 data structure for use in an 

exemplary implementation of the invention. The fimction lookup table is as in table 270 in 
FIG. 2. 

In order to provide access of an original function to the user-supplied fimction, the 
user supplied function accesses the function lookup table 600. The user-supplied fimction 
30 will send the name of the original function and receive in return the address of the original 

function. Thereafter, the user-supplied function will use the address of the original function to 
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invoke the original function. 

The function lookup table data stmcture 600 includes at least one entry, represented in 
FIG. 600 by the rows, in which the address of the original instrumented function is associated 
with the address of the original instrumented function. For example, the name of the original 
5 function is stored in the first column and the address is stored in the second column of the 
function lookup table 600. 

Function lookup table 600 retains access information of the original function to enable 
the user-specified function to access the original function. In one embodiment, function 
lookup table 600 is stored in the instructed executable file. In another embodiment, functions 
10 LookupFunctionAddressO and LookupMethodAddress() enable the user-supplied function to 
locate the original function address without knowing the location of the original function. 
Functions LookupFunctionAddressO and LookupMethodAddressQ are supported or hosted by 
an injector runtime library, such as module 280 in FIG. 2, that executes during the execution 
of the instrumented executable file. 

1 5 More specifically, where a user-supplied function B_W() that resides in a DLL 

replaces, or instruments, original function B() in the executable file, as in Table 4, the function 
B_W() will be modified as follows in Table 5 in order to accomplish a call to the original 
function that B_W() replaces: 



20 void b)(int); 

{ 

void b)(int); 

b=LookupFunctionAddress("B") 
b(z); 

25 }; 

Table 5 
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Overloaded Functions and Methods 

Determining if the function is overloaded, as in action 320 in FIG. 3, in one 
embodiment is a simple name match. For example, in an executable file in which the source 
code was written in C++, a function name can be viewed as mangled or unmangled. 
5 Mangling is well-known to those skilled in the art as generating a unique name for each 
function that is used for compiling and linking purposes. If more than one function has the 
same name, it is considered to be overloaded. In order for the compiler to be able to 
unambiguously identify which is the appropriate function, the function arguments must differ 
in at least one way. For example, where four overloaded SetRetumValue methods exist as 
1 0 defined below: 

void SetRetumValue(char const chRetum Value); 
void SetReturnValue(int const nRetumValue); 
void SetReturnValue(unsigned int const uReturn Value); 
void SetReturnValue(void ^ const pRetumValue); 

15 

The unmangled names of all of the above functions are SetReturnValue. Each 
function differs only in the parameter list. The mangled name counterparts of these methods 
will consist of the base name, plus an encoding technique that specifies the number and types 
of method arguments. For example: 

20 

?SetRetumValue@CSetPointTrace@@QAEXD@Z 
?SetRetumValue@CSetPointTrace@@QAEXH@Z 
?SetRetumValue@CSetPointTrace@@QAEXI@Z 
?SetReturnValue@CSetPointTrace@@QAEXQAX@Z 
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When instrumenting, the system will search for all functions containing the same base 
function name. If more than one has been found, it is known to be overloaded. 

For an overloaded function, an attempt to find the match function in the executable file 
5 using the function name with its list of parameter types, will be performed. For an non- 
overloaded function, an attempt to find the match function in the binary using only the 
function name as the search key, will be preformed. 



Set Point Management and Run-time 

1 0 Set point management enables fault simulation and dynamic control of the user- 

supplied function and the original function. Set point management is accomplished by adding 
set point management control functions to the user-supplied function. The control function 
accesses one or more data files, such as an initialization (INI) file, to retrieve control and 
command information. Enhancing a user-supplied function to include set point management 

15 is accomplished by invoking a set point management interface to determine if a set point 

management component indicates that a specified threshold has been reached. For example, a 
user-supplied function C_W() incorporates set point management as shown below in Table 6 



20 int C_W(int z) 

{ 

if (spm.triggeredO) 

{ 

return error; 

25 } 

CLookup("C"); 
return C(z); 

}; 
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Table 6 



The user-supplied function C_W in Table 6 invokes a set point management function 
component "spm" and sends the message "triggered" in order to determine if the set point 
5 management component has reached a threshold value. If so, then an error is returned, 
otherwise, the address of the original function C() that C_W() replaced is invoked and the 
execution of C_W() ends. 

The run-time module that hosts functions LookupFunctionAddressQ and 
LookupMethodAddressO also manages a master lookup table, as in master 290 in FIG. 2. 

10 More specifically, the master lookup table maps the base addresses of the instrumented 

function lookup tables, as in table 270 in FIG. 2, to the names of the instrumented executable 
file. The master lookup table is created at runtime by the injector runtime library hosting the 
lookup function and method functions. In other words, a table that maps the base address of 
each instrumented executable file to the address of the function lookup table, as in table 270 in 

15 FIG. 2, of the associated instrumented executable file is created at runtime by the injector 
runtime library, as in injector runtime library 280, hosting the lookup function and method 
functions. The master lookup table is a global array that resides in the run-time DLL. Each 
entry of this master lookup table contains the base address of the instrumented binary and the 
address of the function lookup table that contains the original function address prior to being 

20 wrapped or instrumented. 



Fault Simulation 

Fault simulation is accomplished in the set point management component by 
determining is a threshold has been reached. The threshold is determined by specifications 
25 stored in an external data source, such as an initialization (.INI) file. Examples of thresholds 
are trigger every nth call, trigger over n calls, trigger every n bytes communicated, and trigger 
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over n bytes communicates, sleep (i.e. pause) action, break into debugger, and trigger alert. 
Other specifications that the fault simulation data source contain a setting section of 
specification that is acted upon once at the beginning of execution, and includes a refresh 
interval and a random seed, (i.e. psuedo-random reproduction) specification, a global section 
5 of specifications that are applicable to all instrumented functions, a group section of 
specifications that identifies groups of instrumented functions and a local section of 
specifications that set specifications for individual instrument functions. 

Fault Detection 

1 0 Fault detection is implemented through a set point management function 

ControlDetectFault(). A user-supplied function checks the return value of a call to the 
original function and verifies that it has succeeded. If it has not succeeded, the user-supplied 
function calls the FaultDetected() method, which, when activated, writes an entry into the 
current log stream and execute any predefined actions via action setpoints. 

15 

Conclusion 

A method and system for instrumenting an original function in an executable file using 
a user-supplied function, in a manner that enables the user-supplied function to call the 
original function, regardless of whether the original function is imported from a dynamic link 

20 library or is contained within, embedded within, internal to, local in, or defined in the 

executable file has been described. Although specific embodiments have been illustrated and 
described herein, it will be appreciated by those of ordinary skill in the art that any 
arrangement which is calculated to achieve the same purpose may be substituted for the 
specific embodiments shown. This application is intended to cover any adaptations or 

25 variations of the present invention. 
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The terminology used in this application with respect to functions and methods is 
meant to include all of these environments. The term function is used to describe both 
functions in procedural design components, and methods in object-oriented design 
components. Therefore, it is manifestly intended that this invention be limited only by the 
following claims and equivalents thereof. 
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We claim: 

1 . A computerized method for creating an instrumented executable file, the method 
comprising: 

redirecting an original function in an executable file to a user-supplied function; and 
5 retaining access information of the original function. 

2. The computerized method for creating an instrumented executable file as in claim 1 , 
wherein the user-supplied function is modified to invoke the original function using the 
retained access information of the original function. 

10 

3. The computerized method for creating an instrumented executable file as in claim 1, 
wherein the user-supplied function is in a dynamic linked library, 

4. The computerized method for creating an instrumented executable file as in claim 1, 
1 5 wherein the user-supplied function is not exported during compilation. 

5. The computerized method for creating an instrumented executable file as in claim 1, 
wherein the original function and the user-supplied function have identical prototypes. 

20 6. The computerized method for creating an instrumented executable file as in claim 1 , 
where the user-supplied function is stored in a module that is separate from the executable 
file. 
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7. The computerized method for creating an instrumented executable file as in claim 1, 
wherein the redirecting further comprises modifying the executable file. 



8. The computerized method for creating an instrumented executable file as in claim 7, 
5 wherein modifying the executable file further comprises determining whether the original 
function implements the thiscall calling convention, and when the determination is positive, 
adding instructions to the executable file to perform: 

pushing the register that holds the 'this' pointer onto the stack from the invoked 
original function site when the determining indicates that the function 
10 implements a thiscall calling convention; and 

swapping the return value of the invoking original function on the stack and the 

register that holds the 'this' pointer value on the stack when the determining 
indicates that the function implements a thiscall calling convention. 



15 9. The computerized method for creating an instrumented executable file as in claim 7, 
wherein modifying the executable file further comprises enabling the user-supphed function 
to invoke the function in the executable file. 



10. The computerized method for creating an instrumented executable file as in claim 9, 
20 wherein enabling the user-supplied function to invoke the original function in the executable 
file further comprises: 

adding a jump in the user-supplied function to a function that retrieves the address of 
the original function; and 

adding a jump in the user-supplied-function that invokes the original function using 
25 the address of the original function. 
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1 1 . The computerized method for creating an instrumented executable file as in claim 1, 
further comprising enabling the user-supplied function to alter behavior. 

5 12. The computerized method for creating an instrumented executable file as in claim 1 1, 
wherein enabling the user-supplied function to alter behavior is performed in response to data. 

13. The computerized method for creating an instrumented executable file as in claim 12, 
wherein the data is retrieved from an initialization file. 

10 

14. The computerized method for creating an instrumented executable file as in claim 1 , 
wherein the retaining further comprises: 

saving the address of an original function in a threaded local storage variable; and 

15 creating an entry in a function lookup table associating the address of the original 

function with the name of the original function, wherein the function lookup 
table is in the instrumented executable file. 

15. A computerized method for executing an instrumented executable file, the 
20 instrumented executable file having an original function redirected to a user-supplied 

function, and the user-supplied function having a jump to the original function, the method 
comprising: 

saving the address of the original function in a threaded local storage variable; and 
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invoking the user-supplied function. 

16. The computerized method for executing an instrumented executable file as in claim 
15, further comprising creating a master lookup table at initialization wherein the master 

5 lookup table associates the base address of the instrumented executable file to the address of a 
function lookup table in the instrumented executable file. 

17. The computerized method for executing an instrumented executable file as in claim 
15: 

1 0 wherein original function is in a dynamic link library; and 

wherein the saving and the invoking is performed by a stub function of the original 
fimction, the stub function being located in the instrumented executable file. 

18. The computerized method for executing an instrumented executable file as in claim 
15 15: 

wherein original function is embedded in the instrumented executable file; and 
wherein the saving and the invoking is performed by the original function. 

19. The computerized method for executing an instrumented executable file as in claim 
20 15, further comprising invoking the original function from within the user-supplied function 

using the threaded local storage variable. 

20. The computerized method for executing an instrumented executable file as in claim 
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19, wherein invoking the original function further comprises: 

pushing the register that holds the 'this' pointer onto the stack from the invoked 
original function site when the determining indicates that the function 
implements a thiscall calling convention; and 

5 swapping the return value of the invoking original function on the stack and the 

register that holds the 'this' pointer value on the stack when the determining 
indicates that the function implements a thiscall calling convention. 



21. A computerized method for instrumenting an imported function in an executable file 
1 0 for testing by callers of the imported function, the method comprising: 

adding a wrapper of the imported function to an import data block; 

adding a stub function for the imported function wherein the stub function comprises 
and instruction that saves the original function address to a threaded local 
storage variable and an instruction that causes a jump to the user-supplied 
1 5 function; and 

adding an entry in a function lookup table of the original imported function. 



22. The computerized method for instrumenting an imported function in an executable file 
as in claim 22, the method further comprising: 

20 determining if the prototype of the imported function is correctly specified; and 

indicating an error when the determining indicates an incorrectly specified prototype 
of the imported function. 



23. A computerized method for instrumenting an embedded function in an executable file 
25 for testing by callers of the embedded function, the method comprising: 
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redirecting an embedded function to the wrapper; and 

adding an entry in a function lookup table of the address of the embedded function. 

24. A computerized method for instrumenting an embedded function in an executable file 
5 as in claim 23, wherein the redirecting is accomplished by an instruction that causes a jump to 

the user-supplied function. 

25. A computerized method for instrumenting an embedded function in an executable file 
as in claim 23, the method further comprising; 

10 determining whether the prototype of the embedded function is correctly specified; 

and 

indicating an error when the determining whether the prototype of the embedded 

function is correctly specified indicates an incorrectly specified prototype of 
the embedded function. 

15 

26. A computerized method for instrumenting an embedded function in an executable file 
as in claim 23, wherein the function lookup table is in the executable file. 

27. A computerized method for publishing a function, the method comprising adding an 
20 entry describing the function in a function lookup table in a machine-readable executable file. 

28. A computerized system comprising: 

means for redirecting an original function in an executable file to a user- 
supplied function; and 
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means for retaining access information of the original function. 



29. A computerized system comprising: 

an executable file having a call to an original function, the original function 
5 having an identity comprising a name and a parameter prototype; and 

means for a user-supplied function that includes a call to the original function 
to retrieve stored access information of the original function. 



30. A computerized system comprising: 
10 an executable file having a jump to an original function, the original function 

having an identity comprising a name and a parameter prototype; 
a first software component having a user-supplied function that includes a 

jump to the original function; and 
a second software component for: 

1 5 receiving the identity of the original function; 

receiving the identity of the user-supplied function; 

instrumenting the function in the executable file using the identity of 
the user-supplied function; and 

storing the original function address in the executable file in association 
20 with the name of the original instrumented function. 



31. A computerized system comprising : 

a first module of machine-readable code comprising: 

a first instrumented function call to a first replacement function; and 
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a first data structure associating the identity of the first instrumented 

function with the location of the first instrumented function; and 
a second module comprising the first replacement function, operatively 

coupled to the first module through a jump to the first original function. 

5 

32. The computerized system as in claim 3 1 , 

wherein the first data structure comprises a function lookup table readily 

available for verifying that the threaded local storage variable contains 
the correct original instrumented function address; and 

10 wherein the second module comprises a dynamic linked library. 

33. The computerized system as in claim 31, further comprising a second data structure 
associating the location of the first data structure with the location of the first module. 

1 5 34. The computerized system as in claim 3 1 , further comprising: 
a third module of machine-readable code comprising: 

a second instrumented fiinction call to a second replacement fiinction; 
and 

a second data structure associating the identity of the second 
20 instrumented function with the location of the second 

instrumented Sanction; and 
a fourth module comprising the second replacement fiinction, having a jump to 
the second original function. 

25 35. The computerized system as in claim 31, further comprising; 
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a third module of machine-readable code comprising: 

a second instrumented function jump to a second replacement function; 
and 

a second data structure associating the identity of the second 
5 instrumented function with the location of the second 

instrumented function; and 
wherein the second module further comprises the second replacement function, having 
a jump to the second original function. 

10 36. A computer-readable medium having computer-executable instructions to a cause a 
computer to perform a method comprising; 

redirecting an original function in an executable file to a user-supplied 

function; and 
retaining access information of the original function. 

15 

37. A computer-readable medium having stored thereon a first data structure comprising a 
first module having a second data structure associating the identity of a first instrumented 
function with the location of the first instrumented function. 

20 38. A computer-readable medium having stored thereon a first module comprising a first 
data structure associating the identity of a first instrumented function with the location of the 
first instrumented function. 

39. The computer-readable medium having stored thereon a first module as in claim 38, 
25 wherein the first data structure further comprises a table. 
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40. The computer-readable medium having stored thereon a data structure as in claim 38, 
wherein the first data structure further comprises a threaded local storage variable. 
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FUNCTION INJECTOR 
ABSTRACT OF THE DISCLOSURE 

An original function or method in a machine-readable software component, such as 
5 function in an executable file, is instrumented regardless of whether the function is embedded 
within the machine-readable software component or an imported function residing in another 
DLL. When a call to an original function is instrumented, the entry point of the function and 
the identity of the function are stored in the machine-readable software component. A 
function lookup table is used for storing the identity and location of the original function. 
1 0 Storing the information enables a user-supplied function, that is called in substitute for the 

original function, to retrieve or lookup, the location of the original function, using the name of 
the original ftmction as a key, and then call the original function. As a result, the user- 
supplied function acts as a wrapper of the original function and enables fault simulation code 
to control the execution of the original function. STUB for imported fimction 

15 Furthermore, a master lookup table that is created at initialization of an injector 

runtime library, identifies the location of the function lookup table using the base address of 
the instrumented executable file. This enables the function lookup table for each instrumented 
executable file to be located, and then searched to identify the location of an instrumented 
function with the instrumented executable file. 



39 





FIG. 2 



200 



( BEGIN ) 



300 



305 



/ 



OPEN A BINARY IMAGE 



310 



READ AN ITEM FROM THE 
WRAP FUNCTION UST 



/ IS 
NO ^FUNCTION 
4MP0RTED? 

1S-^320 

FUNCTION \ NO 
}VERL0ADED2 



315 



YES 



365 



LOGGING 
ERROR 



YES 

325 

NO FUNCTION^ 
PROTOTYPE correctly: 
SPECIRED? 

YES 



FUNCTION \ NO 
PROTOTYPE CORRECTLY. 
SPECIRED? 



YES 



LOGGING 
ERROR 



375 



335 



ADD THE WRAPPER OF THE 
IMPORTED FUNCTION TO 
THE IMPORT DATA BLOCK 



REDIRECT +he '^t^M^d 

: , FUNCTION TO ITS WRAPPER 



340 



ADD AN ENTRY IN THE 
FUNCTION LOOKUP TABLE 
FOR THE FUNCTION 



I 



380 



REDIRECT 

THE IMPORTED FUNCTION 
TO ITS WRAPPER 



385 




ADD AN ENTRY IN THE 
FUNCTION LOOKUP TABLE 
FOR THE IMPOR TED FUNCTION 
I 



PUSH THE ECX REGISTER ONTO THE STACK 
mOM THE CALLED FUNCTION SITE AND 
SWAP THE CALLEE'S RETURN VALUE AND 
THE ECX REGISTER VALUE ON THE STACK 



FIG. 3 



NEXT ITEM 
AVAILABLE IN THE 
YES^RAP FUNCTION 

STl^390 



( END ) 




^00 



Q 

m 
a 

yj 

ni 

Q 
flJ 

m 
a 

Q 



0 



instrument 



executable 
program 



DLL 




instrument 
onsSuctiof) 
source 



FIG. 5 



500 



FIG. 6 



600 



a 

111 
o 

yj 
fj 

U1 



o 
nj 

u 

m 

Q 
G 



Attorney Docket No. 777.364US1 

SCHWEGMAN, LUNDBERG, WOESSNER & KLUTH, P.A. 

United States Patent Application 

COMBINED DECLARATION AND POWER OF ATTORNEY 

As a below named inventor I hereby declare that: my residence, post office address and citizenship are as 
stated below next to my name; that 

I verily believe I am the original, first and joint inventor of the subject matter which is claimed and for which 
a patent is sought on the invention entitled: FUNCTION INJECTOR . 

The specification of which is attached hereto. 

I hereby state that I have reviewed and understand the contents of the above-identified specification, 

including the claims, as amended by any amendment referred to above. 
* 

I acknowledge the duty to disclose information which is material to the patentability of this application in 
•accordance with 37 C.F.R. § L56 (attached hereto). I also acknowledge my duty to disclose all information known 
to be material to patentabihty which became available between a filing date of a prior application and the national or 
PCT international filing date in the event this is a Continuation-In-Part application in accordance with 37 C.F.R. 

ill I hereby claim foreign priority benefits under 35 U.S.C. §1 19(a)-(d) or 365(b) of any foreign application(s) 
fo£|)atent or inventor's certificate, or 365(a) of any PCT international apphcation which designated at least one 
cokitry other than the United States of America, Usted below and have also identified below any foreign application 
forpatent or inventor's certificate having a fiHng date before that of the apphcation on the basis of which priority is 
clf]|ned: 

Nd such claim for priority is being made at this time. 

Ri I hereby claim the benefit under 35 U.S.C. § 1 19(e) of any United States provisional apphcation(s) hsted 
brffSw: 

Nbfsuch claim for priority is being made at this time. 

I hereby claim the benefit under 35 U.S.C. § 120 or 365(c) of any United States and PCT international 
application(s) listed below and, insofar as the subject matter of each of the claims of this apphcation is not disclosed 
in the prior United States or PCT international apphcation in the manner provided by the first paragraph of 35 U.S.C. 
§ 112, 1 acknowledge the duty to disclose material information as defined in 37 C.F.R. § 1.56(a) which became 
available between the fihng date of the prior application and the national or PCT international fihng date of this 
apphcation: 



No such claim for priority is being made at this time. 



Attorney Docket No.: 777.364US1 

Serial No. not assigned 

Filing Date: not assigned 



Page 2 of 4 



I hereby appoint the following attomey(s) and/or patent agent(s) to prosecute this application and to transact 
all business in the Patent and Trademark Office connected herewith: 





Ppo Xfn Ad AQA 


l-Tot^nc P *^"Kp"**f T 
xldlTlS, ivODcri J . 




J / ,J^O 


i\Icl4rCll, Waller W . 


Ppcr "NTa 9S '^IQ 
Ixcg. iNU. iJjJjy 


/TLllgllll, J . iVildldei 


IVCg. iNU. AH^y LO 


Huebsch, Joseph C. 


Reg. No. 


Al fH'X 


Kjiij Alien J . 




ocnucy, JL' wdyiic i^. 


T?PCT Mn P A'\ QA7 


Tiifl/^rf^^rtr* ri P«:i1+i T 

JUrKOVlCn, ralu J. 


P OCT Wr\ 

Keg. XNO. 


AA fil "X 


Padys, Danny J. 


Keg. INO. jj,Djj 


r>iaiii/Ui, iiiuuiiiy Lj, 


T?pcT Mo "XQ A 
Ivcg. INU. jy,DiU 


rvdUo, J dual iVl. 


P (a ^Tf^ 

i\.eg. iNO. 


J 1 ,DJv 


r alKci, J , JS.ev Hi 




Billion, Richard E. 


K.eg. INO. jZ,cSjO 


Kaufrnanii, John D. 


Reg. No. 


OA HM 


Peacock, Gregg A. 


Keg. iNO. H-JjUUl 


Black, David W. 


Reg. No. 42,331 


Klima-Silberg, Catherine L 


Reg. No. 


40,052 


Perdok, Monic[ue M. 


Reg. No. 42,989 


Brennan, Leoniede M. 


Reg. No. 35^832 


Kluth, Daniel J. 


Reg. No. 


32J46 


Polglaze, Daniel J. 


Reg. No. 39^801 


Brennan, Thomas F. 


Reg. No. 35,075 


Lacy, Rodney L. 


Reg. No. 


41,136 


Prout, William F. 


Reg. No. 33,995 


Brooks, Edward J., Ill 


Reg, No. 40,925 


Leffert, Thomas W. 


Reg. No. 


40,697 


Sako, Katie E. 


Reg. No. 32,628 


Chu, Dinh CP 


Reg. No. 41,676 


Lemaire, Charles A. 


Reg. No. 


36,198 


Schiimm, Sherry W. 


Reg. No. 39,422 


Clark, Barbara J. 


Reg, No. 38,107 


Litman, Mark A. 


Reg. No. 


26,390 


Schwegman, Micheal L. 


Reg. No. 25,816 


Crouse, Daniel D. 


Reg. No. 32,022 


Lundberg, Steven W. 


Reg. No. 


30,568 


Slifer, Russell D. 


Reg. No. 39,838 


Dahl, John M. 


Reg. No. 44,639 


Mack, Lisa K. 


Reg. No. 


42,825 


Smith, Michael G. 


Reg. No. 45,368 


Drake, Eduardo E. 


Reg. No. 40,594 


Maki, Peter C. 


Reg. No. 


42,832 


Speier, Gary J. 


Reg. No. P-45,458 


Eliseeva, Maria M. 


Reg. No, 43,328 


Malen, Peter L. 


Reg. No. 


44,894 


Steffey, Charles E. 


Reg. No. 25,179 


Embretson, Janet E. 


Reg. No. 39,665 


Mates, Robert E. 


Reg. No. 


35,271 


Terry, Kathleen R. 


Reg. No. 31,884 


Fogg, David N. 


Reg- No. 35,138 


McCrackin, Ann M. 


Reg. No. 


42,858 


Tong, Viet V. 


Reg. No.P-45,416 


Fordenbacher, Paul J, 


Reg. No. 42,546 


Nama, Kash 


Reg. No. 


44,255 


Viksnins, Ann S. 


Reg. No. 37,748 


Forrest, Bradley A. 


Reg, No. 30,837 


Nelson, Albin J. 


Reg. No. 


28,650 


Woessner, Warren D. 


Reg. No. 30,440 



I hereby authorize them to act and rely on instructions from and communicate directly with the person/assignee/attomey/ 
firm&rganization/who/which first sends/sent this case to them and by whom/which I hereby declare that I have consented after full 
disclosure to be represented unless/until I instruct Schwegman, Lundberg, Woessner & Kluth, P. A. to the contrary. 

Plej§e direct all correspondence in this case to Schwegman, Lundberg, Woessner & Kluth, P.A. at the address indicated below: 
m P*0. Box 2938, Minneapolis, MN 55402 

Ij^ Telephone No. (612)373-6900 



" ' I hereby declare that all statements made herein of my own knowledge are true and that all statements made on information and 
beEef are believed to be true; and further that these statements were made with the knowledge that willful false statements and the like so 
m^ are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that such willful false 
stafMnents may jeopardize the validity of the application or any patent issued thereon. 

FilliNanie of joint inventor immber 1: Jack Niewiadomski 

Ciilenship: United States of America Residence: Issaquah, WA 

Pdsl Office Address: 1423 NE Katsura Street 

Issaquah, WA 98029-7634 

Signature: Date: 

Jack Niewiadomski 



Full Name of joint inventor number 2 : Lynn Tang 

Citizenship: United States of America Residence: Issaquah, WA 

Post Office Address: 257 1 7 SE 40th Street 

Issaquah, WA 98029 

Signature: Date: 

Lynn Tang 



X Additional inventors are being named on separately numbered sheets, attached hereto. 



Attorney Docket No.: 777.364US1 Page 3 of 4 

Serial No. not assigned 

Filing Date: not assigned 

I hereby declare that all statements made herein of my own knowledge are true and that all statements made on information and 
belief are believed to be true; and further that these statements were made with the knowledge that willful false statements and the like so 
made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any patent issued thereon. 

Full Name of joint inventor number 3 : A.S. Sivakumar 

Citizenship: Canada Residence: Redmond, WA, Canada 

Post Office Address: 15835 NE91st Way 

Redmond, WA 98052 

Canada 

Signature: Date: 

A.S. Sivakumar 



Full Name of inventor: 

Citizenship: Residence: 
Post Office Address: 



Sigi^ture; Date: 



FuffName of inventor: 

CilSsenship : Residence : 

Pdst Office Address: 



Si^ature: Date: 



Full Name of inventor: 

Citizenship: Residence: 
Post Office Address: 



Signature: 



Date: 



Attorney Docket No/ 777.364US1 

Serial No. not assigned 

Filing Date: not assigned 



Page 4 of 4 



§ 1.56 Duty to disclose information material to patentability. 

(a) A patent by its very nature is affected with a public interest. The public interest is best served, and the most effective patent 
examination occurs when, at the time an application is being examined, the Office is aware of and evaluates the teachings of all mformation 
material to patentability. Each individual associated with the filing and prosecution of a patent application has a duty of candor and good 
faith in dealing with the Office, which includes a duty to disclose to the Office all information known to that individual to be material to 
patentability as defined in this section. The duty to disclose information exists with respect to each pending claim until the claim is canceled 
or withdrawn from consideration, or the application becomes abandoned. Information material to the patentability of a claim that is 
canceled or withdrawn from consideration need not be submitted if the information is not material to the patentability of any claim 
remaining under consideration in the application. There is no duty to submit information which is not material to the patentability of any 
existing claim. The duty to disclose all information known to be material to patentability is deemed to be satisfied if all information known 
to be material to patentability of any claim issued in a patent was cited by the Office or submitted to the Office in the manner prescribed by 
§§ 1.97(b)-(d) and 1.98. However, no patent will be granted on an apphcation in connection with which fraud on the Office was practiced 
or attempted or the duty of disclosure was violated through bad faith or intentional misconduct. The Office encourages applicants to 
carefully examine: 

(1) prior art cited in search reports of a foreign patent office in a counterpart application, and 

(2) the closest information over which individuals associated with the filing or prosecution of a patent apphcation believe any 
pending claim patentably defines, to make sure that any material information contained therein is disclosed to the Office. 

j^) Under this section, information is material to patentability when it is not cumulative to information already of record or being 
ma3§ of record in the application, and 

^^ -^ (1) It establishes, by itself or in combination with other information, a prima facie case of unpatentability of a claim; or 

n j (2) It refutes, or is inconsistent with, a position the applicant takes in: 

III (i) Opposing an argument of unpatentability relied on by the Office, or 

f (ii) Asserting an argument of patentability. 

A Ifima facie case of unpatentability is established when the information compels a conclusion that a claim is unpatentable under the 
prejabnderance of evidence, burden-of-proof standard, giving each term in the claim its broadest reasonable construction consistent with the 
specification, and before any consideration is given to evidence which may be submitted in an attempt to estabhsh a contrary conclusion of 
palrfitability. 

Li 

(c) Individuals associated with the filing or prosecution of a patent application within the meaning of this section are: 

( 1 ) Each inventor named in the application: 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Every other person who is substantively involved in the preparation or prosecution of the application and who is 
associated with the inventor, with the assignee or with anyone to whom there is an obligation to assign the application. 

(d) Individuals other than the attorney, agent or inventor may comply with this section by disclosing information to the attorney, 
agent, or inventor. 



